[mypyc] Reduce impact of immortality on reference counting performance #18459
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For example, module namespace dictionaries could reasonably be immortal. Still treat lists as non-immportal, since the performance hit be too high otherwise.
I'm not convinced that it's any better. Getting the address of None requires a memory read, so we'd have an extra memory read in the slow path.
jhance
approved these changes
Jan 21, 2025
x612skm
pushed a commit
to x612skm/mypy-dev
that referenced
this pull request
Feb 24, 2025
python#18459) Fixes mypyc/mypyc#1044. The addition of object immortality in Python 3.12 (PEP 683) introduced an extra immortality check to incref and decref operations. Objects with a specific reference count are treated as immortal, and their reference counts are never updated. It turns out that this slowed down the performance of certain workloads a lot (up to 70% increase in runtime, compared to 3.11). This PR reduces the impact of immortality via a few optimizations: 1. Assume instances of native classes and list objects are not immortal (skip immortality checks). 2. Skip incref of certain objects in some contexts when we know that they are immortal (e.g. avoid incref of `None`). The second change should be clear. We generally depend on CPython implementation details to improve performance, and this seems safe to do here as well. The first change could turn immortal objects into non-immortal ones. For native classes this is a decision we can arguably make -- native classes don't properly support immortality, and they can't be shared between subinterpreters. As discussed in PEP 683, skipping immortality checks here is acceptable even in cases where somebody tries to make a native instance immortal, but this could have some performance or memory use impact. The performance gains make this a good tradeoff. Since lists are mutable, they can't be safely shared between subinterpreters, so again not dealing with immortality is acceptable. It could reduce performance in some use cases by deimmortalizing lists, but this potential impact seems marginal compared to faster incref and decref operations on lists, which are some of the more common objects in Python programs. This speeds up self check by about 1.5% on Python 3.13. This speeds up the richards benchmark by 30-35% (!) on 3.13, and also some other benchmarks see smaller improvements.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes mypyc/mypyc#1044.
The addition of object immortality in Python 3.12 (PEP 683) introduced an extra immortality check to incref and decref operations. Objects with a specific reference count are treated as immortal, and their reference counts are never updated.
It turns out that this slowed down the performance of certain workloads a lot (up to 70% increase in runtime, compared to 3.11). This PR reduces the impact of immortality via a few optimizations:
None).The second change should be clear. We generally depend on CPython implementation details to improve performance, and this seems safe to do here as well.
The first change could turn immortal objects into non-immortal ones. For native classes this is a decision we can arguably make -- native classes don't properly support immortality, and they can't be shared between subinterpreters. As discussed in PEP 683, skipping immortality checks here is acceptable even in cases where somebody tries to make a native instance immortal, but this could have some performance or memory use impact. The performance gains make this a good tradeoff.
Since lists are mutable, they can't be safely shared between subinterpreters, so again not dealing with immortality is acceptable. It could reduce performance in some use cases by deimmortalizing lists, but this potential impact seems marginal compared to faster incref and decref operations on lists, which are some of the more common objects in Python programs.
This speeds up self check by about 1.5% on Python 3.13. This speeds up the richards benchmark by 30-35% (!) on 3.13, and also some other benchmarks see smaller improvements.